In most computer networks it is desirable to have the capability to download, i.e., transfer, data from one computer to another. Typically, data is downloaded from one computer on the network, such as an information provider's site on the Internet, to another site, i.e., computer, where the data is to be used. A file containing data, such as an executable program, graphics or other information, typically is made available for download at one or more sites. The availability of the file is advertised to potential users. Individuals who are interested in using the file access the site to download the file. This kind of information distribution reduces costs and enables efficient tracking of the use of the information.
There are several applications that provide a protocol for downloading files from a server computer to a client computer on a network. Example applications which use the Internet or other TCP/IP-based network include servers and clients that implement the hypertext transfer protocol (HTTP) and the file transfer protocol (FTP). A particular problem with downloading information using applications that support these protocols is that the server application relies solely on the underlying transport protocol for reliability in the delivery of the data. If an error occurs during transmission of the data, the download simply terminates. For the download to complete successfully, the operation must be manually tried again, and the entire file must be downloaded. Such a process can be time consuming and frustrating, especially if the download is almost complete when a failure occurs.
However, the FTP specification, defined in Internet Request For Comments (RFC) 959, includes a restart procedure by which an interrupted FTP service command can be restarted from the point where it was interrupted. This restart procedure is defined for only two of the three modes in which data transfer can occur: block mode and compressed mode. In block mode, data is transmitted as a series of data blocks preceded by one or more header bytes. One of these header bytes includes descriptor codes, which may indicate a restart marker. In compressed mode, transmitted data includes regular data, compressed data and an escape sequence of two bytes. The escape sequence also includes descriptor codes that have the same meaning as in block mode.
To support restart in FTP, the sender of data must send data in block mode or compressed mode and insert a restart marker, or marker code, in the data stream with some marker information. The marker information has meaning only to the sender, and could represent a bit-count, a record-count, or any other information by which a system may identify a data checkpoint. The receiver of data, if it implements the restart procedure, then marks the corresponding position of this marker in the receiving system. In the event of a failure, the user sends a command called RESTART, with a marker code as its argument. The sender then skips over the file specified by the marker code to the data checkpoint specified by the marker code. The RESTART command must be immediately followed by whatever service command was interrupted, such as a read (RETR), write (STOR), directory (LIST) or append (APP). This restart procedure requires both the server to maintain a mapping between data checkpoints and marker codes for each operation and the client to monitor the marker codes received. Moreover, these commands are initiated manually by a user using the FTP client application.
Most currently available server and client programs that support FTP do not support block or compressed mode transfers, and generally support only a third mode of transfer, called stream mode. Most browsers for the Internet also use only this mode of transfer for communication using HTTP. In stream mode, data is transmitted as a stream of bytes, without restriction on the representation type used. If the structure of the data is a file structure, an end-of-file (EOF) indication is indicated by the sending host closing the data connection and all bytes are data bytes. The FTP specification does not define any restart procedure for stream mode transfers. Accordingly, most currently available server and client programs that support FTP also do not support the RESTART command. If a failure occurs during a download, the operation must be manually tried again, and the entire file must be downloaded, obliging an individual to be present during the download.
Similarly, browsers using the HTTP protocol do not support any restart procedure. A proposed specification for a new version (1.1) of HTTP includes a range header in a GET message to enable partial transfers and is intended to reduce unnecessary network usage. See Internet Request for Comments (RFC) 2068. However, the use of a partial GET command by the client is not specified. The HTTP 1.1 specification as proposed also states that a client should retry a request if a connection closes before any status, or a continue response, is received from the server. However, there is no specification regarding error handling if data is received from the server before a connection closes. Apparently, if a failure occurs during a download, the operation must be manually tried again, and the entire file must be downloaded, obliging an individual to be present during the download.
Accordingly, a general aim of this invention is to provide a download process and mechanism that simplifies the download process, and improves the likelihood of successful completion of the download. This functionality also allows the individual not to be present during the download.